COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂23-JUL-75  1342		network site AI
C00042 ENDMK
C⊗;
∂23-JUL-75  1342		network site AI
 Date: 23 JUL 1975 1642-EDT
 From: IAN at MIT-AI
 To: jmc at SU-AI
 
 Clowes 
 home(0273) Lewis 3540
 work(0273) 66755
 
 Hayes
 home (0206) 5630
 work (0206) 44144
 
 -------
 
∂21-JUL-75  1114		1,TOB
 Dave Grossman will be here sometime in the
 interval Aug 14-21.
 Tom

∂17-JUL-75  0909		network site SUMEX
 Date: 17 JUL 1975 0909-PDT
 From: AMAREL at SUMEX-AIM
 Subject: YOUR VISIT TO LAJOLLA
 To:   JMC at SU-AI
 cc:   AMAREL, DESPAIN at ISI, AMPETERSON at ISI, JASON at ISI
 
 JOHN,   FRIDAY, JULY 25, LOOKS OK FOR YOUR VISIT. DON LEVINE FROM OUR 
 GROUP WILL GET IN TOUCH WITH YOU TO MAKE THINGS DEFINITE.
    REGARDS,  SAUL
 -------

∂17-JUL-75  1230		network site MLTX
 From: Markowitz.CPCen at mit-multics
 Date: 07/17/75 1532-edt
 
 
 Subject: computing report
 From: Markowitz
 
 I have just recvd
 messages about rand et al report on computing resources.
 
 Normally, I would not subject you all with my comments,
 but as there is some agreement, I am including a copy
 of my comments (rendered a month or so ago) below.
 
 My most recent comments were that the rec's be
 changed to:
 
 proceed immediately to find suitable replacement
  for TENEX;
 
  support only those mods which are absolutely necessary
  until TENEX replacement is available.
 
 Of course, that is a strong position, but then my more
 reasoned comments (below) had no impact.
 
 joe
 -----------
 
 
 
 
 
 
 
 
 
 To: Weiner -at rand-rcc
 
 From: Markowitz -at mit-multics
 
 Re: Draft Report on Computing Resources (12 May)
 
 
 Some general comments first.-
 
      I think there needs to be some distinction
 between: (1) identifying computer resources likely to
 be needed by ARPA/IPTO contractors in the near term,
 and (2) identifying computer R&D problems which ARPA
 could profitably address.  Items in the report should
 be identified as addressing whichever (or both) theme.
 
      Also, there are some implicit assumptions being
 made about the purposes (original and current) of the
 network which should be spelled out.  A goal of the
 network, resource sharing for better resource
 utilization is served by lots of PDP-10's on the
 network; however, the goal of experimenting with a
 diversity of machines is poorly served by homogeneity.
 There are numerous examples of protocols and
 conventions agreed upon by hosts which embodied
 diversity, but subsequently the tenex-cabal took
 certain shortcuts to the detriment of disimilar hosts.
 
      Of course, our emphasis is on Multics.  Perhaps
 this interest is parochial.  At any rate, I see little
 recognition in the report of its continuing utility in
 ARPA's new computing directions.  This is probably
 unfortunate for it contains some features never to be
 found in tenex -- features which admirably suit it for
 ARPA's customers.  Controlled sharing is a prime
 example: Multics will probably soon become the first
 ever system to achieve multi-level secure
 certification.
 
      However, the ommission of machines like
 Multicsfrom the report, and the concentration on Tenex'
 highlights another issue.  ARPA is under increasing
 pressure to transfer in shorter time frame the fruits
 of its R&D.  Newer ipto programs are designed with this
 goal in mind... the VLDB program, for example.
 Mightn't there be a certain emphasis on machines which
 have data management facilities?  machines on which
 
 
 
 
 
 
 
 
 
 
 
 
 real users exercise real large files for real?
 
      To urge ARPA to emphasize a machine which is not
 quite in production ... let alone in widespread use in
 the target community needs some explaining.  Perhaps
 the explanation is that users in the target community
 just don't know what's good for them. Or, perhaps they
 know something we don't.  Perhaps Tenex,  while
 unsuitable for some large scale uses, is the optimal
 research machine.  If so, then a careful delineation
 between research and production machines seems in
 order.  More important, an analysis of what
 characteristics of Tenex make it ideal is needed -- a
 set of specifications which the research computing
 resource needs to meet ... and which Tenex happens now
 to approximate ... but which might be better met by
 more recently designed gear.
 
      A similar mis-emphasis may be placed on LISP and
 derivative languages in contrast to overwhelmingly
 popular procedural languages.  Here too, users might
 not know what's best for them, or there may again be a
 schism between research and production.
 
      If the distinction between research and production
 has such important implications for hard and software,
 then a good deal of attention need be paid to the
 implications of that divergence for the ultimate tech
 Xfer which is supposedto be the goal.
 
 Some points specific to the reccomendations.-
 
 re Rec 3:
      we believe that this network file/archive system
 needs effective and flexible user-control of file
 sharing and access, denial of access, write protection,
 etc.  This should be able to be specified by user and
 user subgroups.
 
      This net-archive, in Addition to needing access
 controls (centrally administered??) also needs to
 strive for processor independence, language
 independence, and needs to solve the
 multiple-copies-for-reliability-and-efficiency and
 single-copy-for -consistency dilemma.
 
 re Rec 5 (et al.):
      The network remains unproven as a satisfactory
 
 
 
 
 
 
 
 
 
 
 
 
 means of interconnection between disparate kinds of
 computing resources -- a goal of importance to both the
 civilian and the military communities.  Changes to
 protocols that further stress the existing assumption
 that the network and ARPA computing community consist
 solely of TENEX systems are likely to worsen this
 situation.  More important, ARPA should exercise great
 caution to insure that further TIP modifications to
 provide better TENEX interfacing do not degrade the
 interfaces for non-TENEX sites.
 
 re Rec 6:
      If you really want a reliable operating system,
 use the one the operating system developers have lost
 interest in!
 
 
 Some additional comments:
 
 Is the "view of computing ten years out" the view of
 COMPUTING?
  or ARPA/IPTO research computing?
  or DoD computing?
 
      If ARPA is going to impact the future style of DoD
 computing, we might elaborate on what DoD computing is
 today:
  C-cube (command, control, communic.)
  Report generation
  Acccunting, inventory control etc.
 
 Of course, we can presume tha through ARPA's tireless
 efforts new, less mundane types of computing will be
 introduced.  It is not clear, however, that this will
 reduce the importance or frequency of current
 computing.
 
 
 Also, while we applaud the goal of network wide
 archives, it isn't clear that many IPTO contractors
 share data ... we seem to be unique (but then we're
 HRRO contractors).  If they don't share data, why the
 net-wide file system?  just to give them more and freer
 file space than they could command on their own
 installation?  I assume there is more to it than that.
 Sharing? Survivability? resource utilization?  It might
 be good to set out the goal(s) more clearly here.
 
 
 
 
 
 
 
 

∂17-JUL-75  1538		RAP,MG
 Subject: Death of Reasoning About Programs group. 
 
 I leave  the AI  lab.  at the  end of  august and  so can't  continue
 organising  meetings. If anyone would  like to take over  let me know
 and I'll send  the MAILing list.(actually  - for  those who can  hack
 Stanford - it's RAPPER[RAP,MG])
 
 Bye - Mike. 


∂18-JUL-75  0750		1,MSW @ USCT
 I HAVE TRIED FEW TIMES THIS WEEK TO SEND THIS MESSAGE, AND AS FAR AS
 I CAN TELL IT DID NOT GET THROUGH.
 ED FREDKIN SHOULD BE AT THE VC LODGE UNTILL JUL 22, HIS PHONETHERE
 IS (303)-944-2211.  I GOT SOME PAPERS ON BIOL PROCESS CODDING FROM
 WOOD'S LAB, MORE INFORMATION ON THE SUBJEJT NEXT WEEK.


∂19-JUL-75  1337		1,DEK
 impressions of samet thesis:
 a tour de force (although in some respects brute force, without
 a clear overlying structure). the detailed reading of chapters
 2 thru end disappointed me somewhat, not being as brilliant as i had
 expected them to be after seeing the examples in chapter 1. In spite
 of the flaws, I found it an extremely impressive achievement, liable
 to lead to somethings important.


∂20-JUL-75  1531		BPM,BPM
 I have an operations manual for the Datamedia Elite 2500 terminal and a
 manual on TENEX TVEDIT, which runs on the Datamedia, in case anyone is
 interested.  Datamedia's are currently in use at IMSSS, SUMEX, SRI-AIC,
 and SRI-ARC.  The first three use them to run TVEDIT, the last NLS.
 CC: @SUPER:HVA,TOB,REG,CCG,DCL,JMC,TED,LCS,TW;@CF:TED,TAG,ELM,EHS,TJW;@S:REG,MJC,ME,BCG,BH,SGK,JBR,ALS;@PUN:CCG,DRB,AJC,RAE,JJ,EK,DBL,BPM,DES,LIS


∂20-JUL-75  2244		206,NXL
 I did not have the time during spring quarter to do the FOL mods.
 However , I have figured out how I would like to do them, and I am willing
 to try to arrange to take 2 weeks off from what I am doing at the end of
 the summer to do them.  If you want me to, leave me a message on the
 system, or leave word with Corky, or call me at 56-292-4651 (best time is
 between 10 p.m. and 11 p.m.)  Nick


∂21-JUL-75  1341		network site BBN
 Date: 21 JUL 1975 1639-EDT
 From: TOBIASON at BBN-TENEX
 Subject: Comments
 To:   Weiner at RAND-RCC
 cc:   Corby at MIT-MULTICS, Markowitz at MIT-MULTICS, JMC at SU-AI,
 cc:   Pirtle at I4-TENEX, Stockham at UTAH-10,
 cc:   Sutherland at RAND-RCC
 
 
 From:  Bill Woods
 
 
 
 
 
 
                           Comments
 
 
      I have  read  the  8-July  version  of  the  report  on
 
 Computing Resources and I am relatively content with it.
 
 
      My major comment is  a  perceived  awkwardness  in  the
 
 sentence  (second  paragraph  of  the  view  ten  years  out
 
 section) "The most important function we see for  networking
 
 is  to provide an absolutely reliable and solid network-wide
 
 file system for the research community." I could go with the
 
 wording as it stands, since I think I see what you're trying
 
 to do with it, but as it is, it raises a flag  when  I  read
 
 it.   The  statement  is  so  counter  to any of the obvious
 
 functions of the network (communication,  remote  computing,
 
 and  distributed computation) and made so boldly and without
 
 justification, that it sounds a little  less  than  credible
 
 and  seems  to  dismiss  the  current uses of the network as
 
 insignificant.  I realize that  one  of  the  points  is  to
 
 stress  that  eventually  you  see the role of computational
 
 resource sharing as going down, but  I  still  suspect  that
 
 remote  computing and certain kinds of distributed computing
 
 will still be significant, and its use for communication and
 
 file  exchange  among  the  research community is clearly an
 
 important function in the  program  which  you  outline.   I
 
 suggest the following wording:
 
 
      "Although computational resource sharing will  continue
 
 to  be an important function of the network, we see the most
 
 
                                                     Page   2
 
 
 
 important functions as communication and file exchange among
 
 the  research  community, promoted by an absolutely reliable
 
 and solid network-wide file system."
 
 
      I would then delete the word "but" from the  subsequent
 
 sentence.
 
 
      A second modification, which should be considered,  but
 
 I  do  not necessarily advocate, is to terminate this second
 
 sentence at the semicolon  and  replace  the  portion  which
 
 follows the semicolon with:
 
 
      "Many tasks now being  handled  by  time-shared  medium
 
 sized  computers, such as text creation and modification and
 
 message  handling  will  be   handled   by   small   on-site
 
 miniprocessors,   perhaps  integrated  within  the  terminal
 
 itself.  Computation  and  small/medium  scale  computations
 
 will  be  done on larger, but still relatively small on-site
 
 or remotely connected processors.  These processors would be
 
 located  at  the  user's  site where the usage level is high
 
 enough that  the  idle  time  factor  and  maintenance  cost
 
 sharing  is  outweighed by the communication costs of remote
 
 connection  or  where   bandwidth   or   other   performance
 
 requirements  are  such  that on site location is necessary.
 
 Remotely connected processors of  the  same  sort  would  be
 
 available  at  central  locations for projects for which the
 
 usage level does not justify on site location."
 
 
                                                     Page   3
 
 
 
      This proposal separates  out  the  text  (and  program)
 
 creation  and  editing,  where  fractional second delays are
 
 significant and bandwidth for display driving must be large,
 
 from  the compilation and small job running, where one would
 
 like consistent day to day behavior, but  small  delays  (on
 
 the  order  of a second or two) are not appreciable.  In the
 
 former case,  a  small  local  processor  and  enough  local
 
 storage  for  the  files  one  is  actively  working  on  is
 
 essential.  In the second case, it seems to me that a remote
 
 connection  would  be  satisfactory  providing  it  had  the
 
 reserve processing power  to  do  the  job  with  negligible
 
 delays (e.g., via the logical personal processor).
 
 
      If it can be argued that a processor which can  do  the
 
 editing  tasks that one would like and which is cheap enough
 
 to include in the terminal itself (or at  any  rate  for  an
 
 organization  to  acquire with a comparable amount of effort
 
 and outlay to that now required for a fancy scope  terminal)
 
 would  also  be  able  to  do the compilations and small job
 
 running  outlined,  without  making  it  significantly  more
 
 expensive by doing so, then I would be content to stick with
 
 the scenario outlined in the present document.  If, however,
 
 the  on-site  processor  has to grow appreciably in order to
 
 handle the compilation and small job running, then  I  think
 
 the  two  functions  should  be separated out and a scenario
 
 such as I have outlined above inserted.
 
 
                                                     Page   4
 
 
 
      Feedback is welcome.  
 
 
 
                                    Bill
 
 
 
 End of File
 -------


∂22-JUL-75  1431		NEW,MFB
 HI. ID LIKE TO SEE YOU SOON TO DISCUSS MY FUTURE FUNDING. I AM A TA FOR
 THE SUMMER BUT THAT RUNS OUT IN ABOUT A MONTH. I HAVE PROGRAMS I CAN DEMONSTRATE FOR YOU
 AND WOULD BE GLAD TO TALK ABOUT WHAT I AM DOING. MARTIN BROOKS.


∂23-JUL-75  0121		1,MSW @ USCT
 PLEASE LET ME KNOW WHAT PROGRESS HAVE BEEN MADE. ALSO I WOULD LIKE TO
 HAVE SOME ESTIMATE HOW LONG IT MIGHT TAKE BEFORE WE WILL HAVE
 A FINAL ANSWER.


∂24-JUL-75  1946		ACT,REG
 1. Due to the frequency of errors reported via the SWPCHK feature, I have
 taken Librascope offline.
 2. As I consider myself responsible for the saftey of the file system, etc.
 I refuse to allow the system to be put up with Librascope until it is shown
 to my satisfaction to have been fixed.
 3. If someone from the management would like to override my decision (2)
 you're welcome to put the files back together when they're damaged.
 4. As I suggested two weeks ago, Librascope being down is impacting our
 debugging of the Ampex disk.  Les could allieviate some of these problems
 by causing another disk pack to appear.
 CC: LES;JMC;TED;REG


∂29-JUL-75  1338		S,LES
 Happy days are here again!  It is time for the next ARPA proposal.
 
 It is to cover an 18 month period beginning 1 January 1976 and must
 be in Licklider's hands by August 15.  Backing up for printing and
 transit time, I need the final version of your section by next Monday
 afternoon (August 4).  Since I have a firm commitment to go hiking on
 August 7, there is no room for screwing around. 
 
 The PUB sources of the preceding versions are in [R,LES] under the
 names FRS, ADS, PUS, NLS, HES, and SYS, so you can snarf them.
 When you give me back the revised version, please use the same
 name without the "S" on the end.
 
 If you would like to test-PUB your section, say
 .REQUIRE "HEAD.PUB[R,LES]" SOURCE;
 at the beginning of you file.  I request that you run the source through
 SPELL just before you hand it over.
 
 Here are some specific suggestions for improving the previous proposal
 sections, based on Lick's earlier feedback.
 JMC & RWW: section on FR should show more clearly the connection between
 	the proposed research and the "software problem".
 TW:  try to be more specific about what will be done.
 TOB:  emphasize vision research, downgrade industrial automation.
 
 The general research goals of the preceding proposal need not be changed,
 but you should update the milestones.


∂29-JUL-75  1702		network site MAXC
 Date: 29 JUL 1975 1703-PDT
 From: CARD at PARC-MAXC
 Subject: Telephone conversations with Lick and Atkinson
 To:   AILPI:
 cc:   newell at CMU-10A
 
 This  is my  report on my  telephone conversations  with Lick on
 Sunday 27 Jul 75 and with Dick Atkinson on Monday 28 Jul 75.
 
 (L1) My conversation with Lick is easily summarized.  I told him
 about the meeting and he expressed both satisfaction that he had
 occurred and general approval of what transpired.
 
 (L2)  He had not talked  with George Heilmeier about  it. He had
 talked with Dave Russell.  Dave, by the way, is feeling negative
 about NSF  currently, mostly  in terms  of the  difficulties  in
 transferring the Climate Dynamics program.
 
 (L3) I  expressed our concern about not  having ARPA doors close
 behind  us just  because we  were exploring  these paths.   Lick
 didn't  think  they  would necessarily  so  close,  though  his
 assurances could only be general.
 
 (L4) I  noted that  we were  proceeding openly  about the  whole
 endeavor  (eg,  Rozenfeld  and   Bledsoe  had  sat  in  on  some
 conversations).   He expressed  a little concern that Dick might
 need a  little time within NSF, though agreed  it was better off
 generally as an essentially open matter.
 
 (L5) Lick  felt that  we should  proceed independently.      For
 example, he felt that he  should not necessarily be at a meeting
 with Dick Atkinson.  He would keep in touch directly with Dick.
 
 
 (A1) I  told Dick Atkinson about the meeting  of the ARPA AI Lab
 PIs and that we felt we  had to form a committee to even explore
 the  issue of  possible transfer of  the basic  AI research from
 ARPA to NSF.  I emphasized that we felt strongly we did not have
 the necessary  information  about what  step  to take  and  were
 trying to obtain the options.  I also emphasized that we were of
 mixed  feelings about the  suitability of such  a transfer given
 NSF's history of support to  CS, and ARPA's long history of very
 good support.     I believe  I adequately expressed the range of
 attitudes that exist among us.
 
 (A2)  Dick was infinitely  supportive of the attempt  to find an
 appropiate place  for AI basic research and  firm in his feeling
 that CS  research generally and AI  particularly need support at
 an appropriately  high level.   There were  no surprises here in
 terms of  the position we believed Dick was  taking.  He said he
 had talked with Lick (which  we knew) and with Herb Simon and he
 was generally knowledgeable about the problem.
 
 (A3)  Dick probed continually about  what ARPA's intentions were
 and what  our intentions were.  He did not  seem to feel that he
 had obtained  a clear picture from Lick  about ARPA, though this
 was  probably  in  part  simply  his  need  to  obtain  as  many
 independent fixes as he can.
 
 (A4)  Dick felt that  NSF was  not prepared, either  in terms of
 decisions  or (certainly)  dollars, simply  to take  over the AI
 Labs. (I  did note  explicitly at  one point  that we  were  not
 contemplating pulling out  of ARPA altogether, but were thinking
 initially only in terms of some basic AI research component.) He
 stressed  that  NSF  could  not  move  rapidly  if  it  involved
 primarily NSF funds, though it might if it involved ARPA funds.
 
 (A5)  In  response  to  probes about  what  we  were  seeking  I
 described the  notion of a distributed national  lab, as the one
 concrete idea we had come up  with. I noted that we had homed in
 on  a national  facility since  it seemed  important to preseved
 substantial  funding and  we did not  see how  this could happen
 within the OCA as it  was currently structured.  I noted as well
 that we had talked of being prepared to give up certain kinds of
 partial autonomy as a  necessary prices for a distributed lab to
 be a real thing and not just a name.
 
 (A6)  Dick  was  intrigued with  the  notion  of  a  distributed
 national  center.  He felt  this was consonant with  many of the
 goals NSF  had for the development of  national centers and that
 it  also had some features  that dealt rather well  with some of
 the criticisms that might  arise about direct NSF support of the
 AI Labs.
 
 (A7) Dick said that the development of wholly supported national
 centers was the work of  a good many years. He mentioned 4 years
 as a typical number,  thinking in terms of existing ceneters and
 their  development.   Thus,  one could not  develop such centers
 rapidly.
 
 (A8) Dick felt that a  joint venture by NSF and ARPA offered the
 best  basis for hope. He  did not mean just  a transfer of funds
 (for that  ran into the problem of what  to do when the transfer
 years ran  out),  but as  a  continuing venture,  with  possibly
 gradual  shifting of supporting  roles between ARPA  and NSF. He
 emphasized  again that  much depended on  ARPA''s intentions and
 that he did not have a clear view of these.
 
 (A9)  Dick has been  extremely busy at  NSF -- there  has been a
 complete reorganization  and he has been right  in the middle of
 it. Thus, he has not  done anything about this problem, based on
 the  earlier conversations with  Lick.  In fact, he  has not yet
 talked to Pasta about anything, much less this.
 
 (A10) There  was an amount of jockying (both  by Dick and by me)
 over  who should take what  steps first to reduce  the domain of
 uncertainty --  ie, over who should run with  the ball. Dick was
 rather  clear that he  thought that  we should do  so and should
 start by determining much more precisely ARPA's intentions.
 
 (A11) Dick  was  prepared  to meet  with  us  all at  any  time.
 However, he felt that it  made little sense until there was some
 more definite  information -- information which it  was up to us
 to generate. All he would do in a meeting, say next week, was to
 repeat the  things he  said  to me  and to  express  generalized
 support.
 
 
 *******
 
 So  much   for  reporting.   John  was   going  to   call   Dick
 independently, and I don't know whether he has.
 
 I have certain strong impressions:
 
 (I1)  If we want this  thing (whatever it is)  to happen it will
 require  us  to  take the  initiative  and  to  entrepreneur  it
 seriously.  Though Lick gave  it a start  a few days  ago, he in
 fact also believes that we have to grab control. No one is going
 to present us with a solution, all neatly packaged.
 
 (I2) An attempt to get more information from ARPA is next on the
 agenda.  This is  a step I  can take and  will simply  do so. My
 sending this to Lick is one way of initiating that.
 
 (I3) Meantime,  everyone can decide whether  they want to pursue
 this vigorously or weakly or at all.
 
 *******
 
 Note  that I have added  some people to the  list, namely, Herb,
 becase he is on that committee, and Lick. Maybe others should be
 added as well.
 
 A.N.
 -------


∂30-JUL-75  0211		network site MAXC
 Date: 30 JUL 1975 0110-PDT
 From: NEWELL at PARC-MAXC
 Subject: Correction on prior message
 To:   AILPI:
 cc:   newell at CMU-10A
 
 I  see that the message  I just sent on  conversations with Lick
 and Atkinson suffered from my inexperience with Tenex SNDMSG.
 
 It was sent my Allen Newell, not Stu Card.
 
 The  address list,  for your edification is:  JMC, PHW, Nilsson,
 Hart, Simon, & Licklider
 
 You  should  mail to me at  NEWELL@CMU-10A,  even  though  I  am
 temprarily out at Parc. I check my mail there daily.
 
 A.N.
 
 
 -------